UMTS (Universal Mobile Telecommunications System) is the 3G (3rd Generation) mobile communication system standardised by 3GPP (3rd Generation Partnership Project). The first release of the specification of UMTS was published in 1999 (Release 99). In the mean time several improvements to the standard have been standardized by the 3GPP in Release 4, Release 5 and Release 6. With the desire to support higher data rates, it was decided to develop a new Air interface and also a new evolved radio access network, E-UTRAN (UMTS Terrestrial Radio Access Network). The 3GPP launched a study item “Evolved UTRA and UTRAN” better known as “Long Term Evolution (LTE)”. The study will investigate means of achieving major leaps in performance in order to improve service provisioning, and to reduce user and operator costs. Out of that and because interworking with other radio access technologies should be possible, the need arose for a new evolved Packet Core Network.
An exemplary representation of the E-UTRAN architecture is given in FIG. 1. The E-UTRAN consists of evolved Node Bs (eNB or eNodeB), providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the mobile node.
The eNB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. Further, it performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL-QoS (Quality of Service), cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers. The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME, and to the Serving Gateway (S-GW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNBs.
The S-GW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and Packet Data Network Gateway). For idle state UEs, the S-GW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the S-GW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to UEs. It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN (Serving GPRS Support Node). The MME also terminates the S6a interface towards the home HSS for roaming UEs.
The Packet Data Network Gateway (PDN-GW) provides connectivity for the UE to external packet data networks by being the point of exit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one PDN-GW for accessing multiple PDNs. The PDN-GW performs policy enforcement, packet filtering for each user, charging support, lawful Interception and packet screening. Another key role of the PDN-GW is to act as the anchor for mobility between 3GPP and non-3GPP technologies.
To summarize the above, in order to support the new E-UTRAN access, the new 3GPP Core Network is mainly separated into three logical entities. At first, in the user plane the PDN-GW is the gateway to the external networks and the global mobility anchor for mobility between 3GPP and non-3GPP access technologies (likeCDMA2000, WiMAX or WIFI). Second, another user plane entity being the Serving Gateway is the mobility anchor for mobility between 3GPP accesses (E-UTRAN, UTRAN, GERAN). Thirdly, a Mobility Management Entity is the control plane entity responsible for the mobility management of mobile terminals (also referred to in the following as UEs or MNs) moving between different EUTRAN base stations (eNodeBs) and also responsible for the session management.
The MMEs are connected to the eNodeBs, and one MME might be serving a number of eNodeBs so that multiple MMEs are necessary within the system to cover all eNodeBs. Furthermore, a pool of MMEs might be serving the same set of eNodeBs, e.g. for load balancing reasons.
As described above, the MME is responsible for mobility management and session management. For each mobile terminal attached to an MME, specific mobility management and evolved packet system context information is stored in the MME. These contexts comprise, e.g. the mobility state, the temporary identity, the current Tracking Area List, last known cell, authentication vectors, access restrictions, subscribed QoS profile, subscribed charging characteristics, and for each active PDN connection the APN (Access Point Name) in use, IPv4/IPv6 addresses, PDN-GW address for control plane, and also information for each EPS (Evolved Packet System) bearer within the PDN connection, as for example EPS bearer QoS profile, EPS bearer charging characteristics.
Furthermore, the context for a mobile terminal in an MME might be available even if the mobile terminal is detached from the 3GPP access. This context preservation allows for faster session setup when again switching on in the 3GPP access or when handing over from a non-3GPP access back to the 3GPP access, mainly because signaling with the Home Subscriber Server (HSS) is saved.
The mobility management within the 3GPP system is network controlled and two protocol variants are standardised for the interface between the PDN-GW and the S-GW. One is based on GTP (GPRS Tunneling Protocol), the protocol used in the legacy GPRS (General Packet Radio Service) system, and the other one is Proxy Mobile IPv6 (PMIPv6), developed in the IETF (Internet Engineering Task Force). For interworking with non-3GPP accesses, the mobile terminal can be connected to the Core Network, i.e. the PDN-GW, via PMIPv6 as well, in case the non-3GPP access supports PMIPv6. Alternatively, if the mobile terminal does not support inter-access handover with PMIPv6 or if the non-3GPP access does not support PMIPv6, the mobile terminal can be connected to the Core Network via Client Mobile IP versions, i.e. Mobile IPv4 Foreign Agent Mode (MIP4FA) or Dual Stack Mobile IPv6 (DSMIPv6).
Before a mobile terminal can access a non-3GPP access network, access authentication needs to be performed. If 3GPP based access authentication is applied in the non-3GPP access, i.e. the 3GPP AAA server/HSS authenticates the mobile terminal, EAP-AKA (Extensible Authentication Protocol-Authentication and Key Agreement) is used.
When the mobile terminal is active in a non-3GPP access network there is a local IP address used to route packets to the mobile terminal in the non-3GPP access. This IP address is the Care-of Address in the terminology of Mobile IP. In case of DSMIPv6, the address is assigned to the mobile terminal, and the mobile terminal is sending Binding Updates using its Care-of address to the PDN-GW, which has the function of the Home Agent (HA). In case of PMIPv6, the Care-of address is an address of a Mobile Access Gateway (MAG) that is located in the non-3GPP access network, and the MAG is sending Proxy Binding Updates using its (Proxy-) Care-of Address to the PDN-GW of the 3GPP network, which has the function of the Local Mobility Anchor (LMA).
A possibility to establish in advance contexts and resources in some 3GPP entities is to initiate said establishment by e.g. the AAA (Authentication, Authorization, Accounting) server or HSS by an event and without explicit signalling between the mobile terminal and the MME in the 3GPP access. The event can be for example the authentication of the mobile terminal in a non-3GPP access. In this scenario, in case the AAA server initiates the procedure, it may act as a proxy MME towards the HSS and request context for the mobile terminal and then push the context to the appropriate MME. Additionally the MME may then in advance setup contexts in the eNodeB and trigger bearer creation towards the S-GW.
In case of a handover from a non-3GPP access to a 3GPP access, the mobile terminal sends an Attach Request message to the MME in the 3GPP access (via the eNodeB) after discovering the 3GPP access. In the Attach Request message the mobile terminal indicates in an Attach Type field that it is a handover. In addition, the mobile terminal signals the old Global Unique Temporary Identifier (GUTI) for authentication. Then, the eNodeB derives from the GUTI the mobile terminal's MME and sends the Attach Request message to the MME. If the indicated MME is not associated with the contacted eNodeB, the eNodeB selects another MME and forwards the Attach Request message to this new MME. The new MME (if different from the old MME) retrieves the context (including IMSI, Authentication Quintets) from the old MME and can therefore skip part of the authentication procedure with the MN.
This above procedure is detailed in the following with reference to FIG. 2, which illustrates a signaling diagram for an E-UTRAN initial Attach Procedure.                1. The UE initiates the Attach procedure by the transmission of an Attach Request message (IMSI or old GUTI, last visited TAI (if available), UE Network Capability, PDN Address Allocation, Protocol Configuration Options, Attach Type) together with an indication of the Selected Network to the eNodeB of the 3GPP network. The Attach Type indicates “Handover” in case the UE has already an activated PDN-GW/HA due to mobility within non-3GPP accesses.        2. The eNodeB derives the UE's MME from the GUTI and from the indicated Selected Network. If that MME is not associated with the eNodeB, the eNodeB selects an available MME for serving the UE. The selection is based on network topology, i.e. the selected MME serves the UE's location and in case of overlapping MME service areas, the selection may prefer MMEs with service areas that reduce the probability of again changing the MME. Other criteria for MME selection could include load balancing between MMEs. The eNodeB then forwards the Attach Request message to the new MME.        3. If the UE identifies itself with the GUTI and the MME has changed since detach, the new MME sends an Identification Request (old GUTI) to the old MME to request the IMSI pertaining to the UE. The old MME responds with an Identification Response (including IMSI, Authentication Quintets for the UE). If the UE is not known in the old MME, the old MME responds with an appropriate error cause.        4. If the UE is unknown in both the old MME and the new MME, the new MME sends an Identity Request to the UE to request the UE's IMSI. The UE responds with an Identity Response (IMSI).        5a. If no UE context for the UE exists anywhere in the network, authentication of the UE is mandatory. Otherwise, this step is optional; i.e. when context could be retrieved from the old MME. Authentication between the UE and the new MME is however still necessary.        6. If there are active bearer contexts in the new MME for this particular UE (i.e. the UE re-attaches to the same MME without having properly detached before), the new MME deletes these bearer contexts by sending Delete Bearer Request (TEIDs) messages to the GWs involved. The GWs acknowledge with Delete Bearer Response (TEIDs) messages.        7. if the MME has changed since the last detach, or if it is an Initial Attach, the new MME sends an Update Location message (MME Identity, IMSI, ME Identity) to the HSS.        8. The HSS sends a Cancel Location message (IMSI, Cancellation Type) to the old MME with the Cancellation Type set to Update Procedure. The old MME acknowledges with Cancel Location Ack (IMSI) and removes the MM (mobility management) and bearer contexts.        9. If there are active bearer contexts in the old MME for this particular UE (i.e. the UE did not properly detach before), the old MME deletes these bearer contexts by sending Delete Bearer Request (TEIDs) messages to the GWs involved. The GWs return Delete Bearer Response (TEIDs) messages to the new MME.        10. The HSS sends an Insert Subscriber Data (IMSI, Subscription Data) message to the new MME. The Subscription Data contains the list of all APNs (Access Point Names) that the UE is permitted to access, an indication about which of those APNs is the Default APN, and the ‘EPS subscribed QoS profile’ for each permitted APN. The new MME validates the UE's presence in the (new) TA. If due to regional subscription restrictions or access restrictions the UE is not allowed to attach in the TA, the new MME rejects the Attach Request with an appropriate cause, and may return an Insert Subscriber Data Ack message to the HSS. If all checks are successful, then the new MME constructs a context for the UE and returns an Insert Subscriber Data Ack message to the HSS. The Default APN shall be used for the remainder of this procedure.        11. The HSS acknowledges the Update Location message by sending an Update Location Ack to the new MME. If the Update Location is rejected by the HSS, the new MME rejects the Attach Request from the UE with an appropriate cause.        12. if the PDN subscription context contains no PDN-GW address, the new MME selects a PDN-GW. If the PDN subscription profile contains a PDN-GW address and the Attach Type does not indicate “Handover”, the MME may select a new PDN-GW, e.g. to allocate a PDN-GW that allows for more efficient routing. The new MME selects a Serving-GW and allocates an EPS Bearer Identity for the Default Bearer associated with the UE. Then, it sends a Create Default Bearer Request (IMSI, MME Context ID, APN, RAT type, Default Bearer QoS, PDN Address Allocation, AMBR, EPS Bearer Identity, Protocol Configuration Options, ME Identity, User Location Information) message to the selected Serving-GW.        13. The Serving-GW creates a new entry in its EPS Bearer table and sends a Create Default Bearer Request (IMSI, APN, Serving GW Address for the user plane, Serving GW TEID of the user plane, Serving GW TEID of the control plane, RAT type, Default Bearer QoS, PDN Address Allocation, AMBR, EPS Bearer Identity, Protocol Configuration Options, ME Identity, User Location Information) message to the PDN-GW. After this step, the Serving GW buffers any downlink packets it may receive from the PDN-GW until receiving the message in step 21 below.        15. The PDN-GW returns a Create Default Bearer Response (PDN-GW Address for the user plane, PDN GW TEID of the user plane, PDN GW TEID of the control plane, PDN Address Information, EPS Bearer Identity, Protocol Configuration Options) message to the Serving-GW.        16. The Serving-GW returns a Create Default Bearer Response (PDN Address Information, Serving GW address for User Plane, Serving GW TEID for User Plane, Serving GW Context ID, EPS Bearer Identity, Protocol Configuration Options) message to the new MME. PDN Address Information is included if it was provided by the PDN-GW.        17. The new MME sends an Attach Accept (APN, GUTI, PDN Address Information, TAI List, EPS Bearer Identity, Session Management Configuration IE, Protocol Configuration Options) message to the eNodeB. GUTI is only included if the new MME allocated a new GUTI.        18. The eNodeB sends a Radio Bearer Establishment Request including the EPS Radio Bearer Identity to the UE, and the Attach Accept message will be sent along to the UE.        19. The UE sends the Radio Bearer Establishment Response to the eNodeB. In this message, the Attach Complete Message (EPS Bearer Identity) will be included.        20. The eNodeB forwards the Attach Complete (EPS Bearer Identity) message to the new MME. After the Attach Accept message and once the UE has obtained a PDN Address Information, the UE can then send uplink packets towards the eNodeB which will then be tunnelled to the Serving-GW and PDN-GW.        21. The new MME sends an Update Bearer Request (eNodeB address, eNodeB TEID) message to the Serving-GW.        22. The Serving GW acknowledges by sending Update Bearer Response (EPS Bearer Identity) message to the new MME. The Serving GW can then send its buffered downlink packets.        23. After the MME receives an Update Bearer Response (EPS Bearer Identity) message, if an EPS bearer was established and the subscription data indicates that the user is allowed to perform handover to non-3GPP accesses, and if the MME selected a PDN-GW that is different from the PDN-GW address which was indicated by the HSS in the PDN subscription context, the MME shall send an Update Location Request including the APN and PDN-GW address to the HSS for mobility with non-3GPP accesses.        24. The HSS stores the APN and PDN-GW address pair and sends an Update Location Response to the MME.        
The above explanation of the signalling diagram in FIG. 2 is quite detailed and considers many cases. For simplicity it will be now assumed that a UE is first located in a 3GPP network area, and thus is registered to an MME, including the establishment of context information in the MME. When leaving the 3GPP network into a non-3GPP network, the MME still maintains the context information. However, when eventually returning to the 3GPP network, the UE has moved far away and attaches to an eNodeB, which does not belong to the old MME. Therefore, the old MME can no longer be used, and another MME has to be selected. It is further assumed that the old MME pushes the UE's context information to the new MME. Due to the change of MME, the steps 3, 7, 8, 10 and 11 of the method in FIG. 2 have to be conducted. Step 4 and part of step 5 are not necessary since by retrieving the UE's context information from the old MME, only authentication between MN and the new MME is necessary. In other words, though the new MME does not need to retrieve the authentication vector from the HSS, the UE however still needs to authenticate itself with the new MME. Step 6, relating to bearers which could be still active in the S-GW/PDN-GW for the new MME, would not be necessary since it is assumed that the MN attaches for the first time to the new MME. Further, step 9, relating to deleting bearers in the S-GW/PDN-GW for the old MME, is only necessary if the MN did not correctly detach or handover from the old MME. During the detach or handover procedure from the old MME, the bearers with the S-GW/PDN-GW should have been deleted. However, in case the mobile node is merely switched-off and later switched-on again in the non-3GPP network, it might be that there are still bearers active between the old MME and the S-GW/PDN-GW, in which case step 9 would have to be performed.
It might be even that the old MME deleted the UE contexts, which are thus not available for the new MME, in which case the steps 4 and 5 would have to be conducted as well. This is similar to another exemplary scenario in which the UE made the Initial Attach in the non-3GPP network, and attaches for the first time in the 3GPP network area.
Anyway, these steps (at least steps 3, 7, 8, 10 and 11) introduce an additional delay in the handover procedure.
According to a first set of problem, especially in the case where simultaneous connectivity with multiple radio interfaces is not possible, this MME relocation introduces additional signalling and leads to a handover delay and may cause an interruption of ongoing sessions.
The above architecture describes the non-roaming variant, i.e. the non-3GPP access, the mobile terminal is connected to, has a direct roaming relationship with the home operator of the mobile terminal.
Referring to a second set of problems, however if the non-3GPP access does not have direct roaming relationship with the home operator, a possible variant for the mobile terminal to connect to a PDN-GW in the Home Public Land Mobile Network (HPLMN) is to use a Serving Gateway (S-GW) in a Visited Public Land Mobile Network (VPLMN) as an intermediary between the MAG in the non-3GPP access network and the PDN-GW. Such a connection is called “Chained connection” or “Chaining”. In the Chaining case, the AAA Proxy selects the S-GW in the VPLMN and notifies the MAG in the non-3GPP access about it.
There two types of the Chaining, wherein in both cases PMIPv6 is always applied between the MAG and the S-GW. One case is to use the PMIPv6 Protocol for the signalling and PMIP tunnel for user data transport between the PDN-GW and the S-GW. In this type of the Chaining, the S-GW acts as a PMIP relay which transfers the PBU, PBA and user data between the PDN-GW and the MAG. Another type of the Chaining is to use the GPRS Tunnelling Protocol (GTP) for the signalling and the user data transport between the S-GW and the PDN-GW. In this case, the S-GW acts as a signalling gateway for PMIP and GTP, and also as tunnel-concatenator for the PMIP tunnel and the GTP tunnel between the PDN-GW and the MAG.
In case of a handover of the mobile terminal from the non-3GPP access Chaining case to the 3GPP access network, the previously used S-GW might also need to be relocated. As this S-GW relocation is performed by the MME, the selected S-GW for the 3GPP access network could be different from the former S-GW that was selected by the AAA Proxy and used from the non-3GPP access network.
In addition, there can be other scenarios in which it is necessary to change the Serving-GW. For instance, according to local policy, a specific S-GW is only to be used for MNs in the 3GPP network, but not for those in the non-3GPP network. Thus, when a MN moves to a non-3GPP network area, a new S-GW (e.g. only for MNs in the non-3GPP network) has to be selected, and the data path from the PDN-GW to the MN is relocated to go via the new S-GW instead of via the old S-GW.
Furthermore, during intra-technology handovers, i.e. within the non-3GG network respectively the 3GPP network, a change of the S-GW might be advantageous (e.g. due to route optimizations. Also in this case, the S-GW relocation during the handover takes time and lengthens the handover duration, this being a second problem encountered during handovers.